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Method for calculating hashing of a message in a device 
communicating with a smart card 



Field of the Invention 

5 The invention concerns a method for calculating hashing of a 

message in a smart card. In the following text, a smart card will designate 

all tamper- resistant devices able to store secret data. 

The example that will be used for illustrating the invention is that of 

a WIM (WAP Identity Module) module coupled to a mobile phone. This 
10 smart card could also be a SIM (Subscriber Identity Module) smart card, or 

all other module able to store secret data and to perform Hash functions. 



Prior Art 

The Wireless Application Protocol (WAP) defines an industry-wide 
15 specification for developing applications that operate over wireless 
communication networks. The scope for the WAP Forum is to define a set 
of specifications to be used by service applications. The wireless market is 
growing very quickly, and reaching new customers and services. To enable 
operators and manufacturers to meet the challenges in advanced services, 
20 differentiation and fast/flexible service creation WAP Forum defines a set 
of protocols in transport, security, transaction, session and application 
layers. 

The Security layer protocols in the WAP architecture can be the 
25 Wireless Transport Layer Security (WTLS) or the standard Transport 
Layer Security (TLS) Internet protocol. WTLS provides functionality similar 
to TLS but is more adapted to lower bandwidth communication channels. 
. TLS and WTLS layer operate above the transport protocol layer. They 
provide the upper-level layer of WAP with a secure transport service 
30 interface and also provide an interface for managing (eg, creating and 
terminating) secure connections. The primary goal of the WTLS or TLS 
layers is to provide privacy, data integrity and authentication between two 
communicating applications. 
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For optimum security, some parts of the security functionality need 
to be performed by a tamper-resistant device, so that an attacker cannot 
retrieve sensitive data. Such data is especially the permanent private keys 
used in the WTLS or TLS handshakes with client authentication, and for 
5 making application level electronic signatures (such as confirming an 
application level transaction). 

In particular, when a message has to be hashed in a mobile 
coupled to a WIM module, all the blocks are transferred from the mobile to 
10 the WIM for being hashed. Then, the WIM sends the result to the mobile. 
An example of a WIM implementation is the smart card CAR. In the phone, 
it can be the Subscriber Identity Module SIM card or an external smart 
card. The problem is that, in the WIM, resources are very limited; 
consequently, calculations take a lot of time. 

15 

For example, in WTLS and TLS, the Mobile Equipment sends to the 
server a message called "Finished" message, which is always sent to the 
server at the end of a handshake to verify that the key exchange and 
authentication processes were successful between the mobile and the 

20 server. The Mobile Equipment uses the smart card for calculating the data 
to send in the "Finished" message and also the data that should be 
received from the server. In order to do that, the mobile ME issues the 
"Client Finished Check" and "Server Finished Check" commands to the 
smart card CAR. Using a Pseudo Random Function (PRF), the smart card 

25 calculates a requested number of bytes based on the session master 
secret, and a seed value received from the mobile. The card then returns 
the bytes to be used by the mobile in the "Finished" message. For 
calculating the Client Finished Check data, the mobile uses a primitive 
called WIM-PHash primitive with the following input data parameter: 

30 "client finished" + Hash(handshake_messages) 

The "Hash(handshake_messages) w is defined as the SHA-1 and/or 
MD5 hash (depending on protocol) of the concatenation of all previous 
handshake messages that were exchanged up to but not including the 



"Finished" message. The primitive then returns to the mobile the needed 
data block. 

We will refer the standard for more details about the commands and 
primitives which are cited above. 

5 

In the same manner, for Calculating the server finished check, the 
mobile ME uses the WIM-PHash primitive with the following input data 
parameter: 

"server finished" + Hash(handshake_messages). 

10 The primitive then returns to the mobile the needed data block. 

In SSL, the parameters that are sent to the WIM for the "Finished" 
message are different. When we perform the finished check in SSL, it is 
necessary to perform a hash on: 

15 'handshake_messages + Sender + master_secret + padV. 

Comparing with WTLS and TLS, we see that the Hash should be 
calculated also over the session "master secret" in addition to 
"handshake_messages B . This poses a problem since the mobile ME does 
not know the value of the master secret as it is securely stored in the smart 

20 card CAR and is never exposed externally. Consequently, the following 
data: 'handshake_messages + Sender + master_secret + padV has to 
be sent to the WIM for being hashed. Nevertheless, resources are very 
limited in the WIM, consequently calculations in the smart card take a lot of 
time. 

25 

Invention 

The aim of the invention is to hash a message in an efficient 
manner reducing the consumption of resources in the WIM. 

30 The invention is a method for calculating hashing of a message in a 

device communicating with a smart card, said device and said smart card 
storing the same hash function, the message comprising data blocks 
including secret data and other data, secret data being only known by the 
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smart card. According to the invention, the calculation of the hash of the 
secret data is performed in the smart card and the calculation of the hash 
of all or part of the other data is performed in the device. 

5 We will that, the intermediate result is transmitted from the device to 

the card, or inversely, depending on whether the hash calculation of the 
hash of a data has to be performed by the smart card or the device. 

In this way, the invention avoids time consuming to calculate a Hash 
10 function in the smart card since the device, in particular a mobile phone, 
can usually do it faster as it has a stronger processor. 

It will be easier to understand the invention on reading the 
description below, given as an example and referring to the attached 
15 drawings. 

In the drawings: 

Figure 1 represents an example of a data processing system S in 
which the invention may be applied. 
20 Figures 2-4 are views of different types of messages including 

secret data. 

Detailed Description of Examples Illustrating the Invention 

In order to simplify the description, the same elements illustrated in 
25 the drawings have the same references. 

Figure t represents a system S. In our example, this system 
includes a smart card CAR coupled to a mobile phone ME communicating 
with a server SERV through a network RES. 

30 

Generally, the smart card is used to store and process information 
needed for user identification and authentication. The smart card CAR 
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stores the client sensitive data, especially keys and sessions master 
secrets. 

The smart card cn be a WIM module. The WIM (WAP Identity 
Module) is a security token standardized in the WAP Forum. We will refer 
5 to this standard for more details on the module WIM. As mentioned above, 
the WAP Forum WIM specification describes how the WIM is used with 
TLS and WTLS and in application level services. 

Generally, as mentioned above, when a message includes keys and 
10 master secrets and that this one has to be hashed in a mobile coupled to a 
WIM module, all the blocks are transferred from the mobile to the WIM for 
performing a Hash step. Then, the WIM sends the result to the mobile. All 
operations where keys and master secrets are involved are performed 
internally in the module WIM. 

15 

Generally, a Hash function works on a fixed length of data input and 
the result is carried on to the next iteration. It calculates a hash on the first 
block of the data (64 bytes for SHA-1), then carry the result to the 
calculation of the Hash on the second block and continue like that until all 
20 input data is consumed. 

In our example we want to hash a data input, called message MF in 
the following description, including: 

"PD + SD" 

25 where the V operator means concatenation. 

This data message MF comprises data blocks including 

- secret data SD, which could be the u master secret" data 

- and other data PD, which could be the "handshake_messages" 

30 

According to the invention, the mobile ME can start calculating the 
hash over the other data PD which are public. The result of this calculation 
constitutes an intermediate result R. Then, The mobile ME sends the 
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intermediate result R and the remaining secret data SD to the smart card 
CAR. The smart card continues the hash calculation internally by using the 
intermediate result R, the remaining secret data SD and the additional data 
(e.g. tt master_secreF ) that is kept internally in the smart card CAR. Once 
5 the calculation is finished, the smart card send the corresponding result to 
the mobile ME. 

So, Generally, according to the invention, if a secret data SD is 
followed by the other data PD in the message MF (see figure 4), the smart 

10 card starts calculating the hash of all blocks that include a secret data SD 
and then sends the corresponding intermediate result R to the ME that 
continues the hash calculation by using the intermediate result R and the 
remaining data PD. For example, the data SDC- including secret data is 
hashed in the smartcard. On the contrary, if data PD is followed by the 

is other data SD (see figure 3), the mobile ME starts calculating the hash of 
the data PD and then send the corresponding intermediate result R and 
remaining part RP of last hash block to the smart card that continues to do 
the hash calculation internally by using the intermediate result R, last hash 
block and the remaining data SD. 

20 

Advantageously, if a block includes a part comprising secret data 
SD and another part comprising other data PD, the smart card calculates 
the hash of this block. In this way, the transfer of data is decreased 
between the mobile ME and the smart card CAR. 

25 

This invention also formalizes the way by which the intermediate 
results R are sent to the smart card in order to use the same convention of 
command exchanged between the mobile ME and the smart card CAR for 
other primitives. In our example, the mobile ME will send the hashed 
30 intermediate result R and other data if needed with the "WIM MSE-Sef 
command. These parameters will be put in a newly defined "SSL security 
environment' in the smart card CAR. In our example, The SSL security 
environment will implement acceptance of these parameters via the "MSE- 
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set" command, which should be called before invoking the w PSO" 
command for calculating the "Finished" message. 



In our example, the device is implementing the Transport Layer 
5 Security protocol SSL (Secure Socket Layer) and the smart card is a 
WAP Identity Module (WIM). More specifically, the message MF is called 
"Finished" in the SSL protocol. The secret data SD is an SSL session 
master secret. 

10 The invention also concerns a communication device ME 

characterized in that it includes a program for performing the following 
steps: 

- a hashing step in which all or part of said other data PD are 
hashed in said communication device, 
is - a requesting step in which, said communication system request 

the smart card to perform the hash of all the secret data SD. 

The invention also concerns a smart card CAR characterized in 
that said smart card includes a program for performing, when requested by 
20 the communication device ME, a step of hashing said secret data SD. 

The main advantage of the above solution is speed. It will take more 
time to write the whole data in a file in the WIM and then have the WIM 
read it and hash it. Speed is very important in the handshake and it is very 

25 important to optimise it. If it takes more than a few seconds to establish a 
secure session it is not very convenient for the user. The other advantage 
is to avoid the need to store a big block of data in the WIM for a specific 
primitive. This invention defines a solution for calculating the "Finished" 
message by the WIM module for SSL in an efficient manner and without 

30 the need to send the whole "handshake_messages" data block to store in 
the WIM. For example, In WTLS, protecting secure sessions are relatively 
long living - which could be several days. The invention will avoid frequent 
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full handshakes which are relatively heavy both computationally and due to 
large data transfer. 

Of course, the invention is not limited to SSL but can be used in 
5 other technical fields. 



